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Armoring Solaris 



Figure A 



by Lance Spitzner 

Firewalls are one of the fastest 
growing technical tools in the 
field of information security. 
However, a firewall is only as se- 
cure as the operating system it re- 
sides upon. This article will take a 
step-by-step look at how you can 
best armor your Solaris 
box, both Sparc and x86. 
We'll take a look at tech- 
niques like TCP wrappers, 
shown in Figure A, to 
protect your telnet ses- 
sions. These steps can 
apply to any situation; 
however, we'll be using 
Checkpoint Firewall 1 on 
Solaris 2.6 as an example. 

Installation 

The best place to start in 
armoring your system is 
at the beginning: OS 
installation. Since this is 
your firewall, you can't 
trust any previous instal- 
lations. You want to start 
with a clean installation, 
where you can guarantee 
the system integrity. 

Place your system in an 
isolated network. At no 
time do you want to con- 
nect this box to an active 
network or the Internet, 
exposing the system to a 
possible compromise. To 



get critical files and patches later, 
you'll need a second box that acts as 
a go-between. This second box will 
download files from the Internet, 
and then connect to your isolated, 
configuration "network" to transfer 
critical files. 
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Incoming telnet sessions 
are validated before being 
allowed to execute 



launched by the init process. Many of these 
processes aren't needed. To prevent a script 
from starting, replace the capital S with a low- 
ercase s. That way, you can easily start the 
script again just by replacing the lowercase s 
with a capital S. The following scripts aren't 
needed and pose serious security threats to 
your system: 



Once you've placed your future firewall 
box in an isolated network, you're ready to 
begin. The first step is selecting which OS 
package to load. We recommend End User 
with Online manual pages. The idea is to load 
the minimum installation, while maintaining 
maximum efficiency. The less software that 
resides on the box, the fewer potential secu- 
rity exploits or holes. Anything above the End 
User package, such as Developer, is adding 
useless, but potentially exploitable, software. 
Remember, this is your firewall; it shouldn't 
be running anything else. 

The other option is to load the Core instal- 
lation package, which is smaller and leaner 
than the End User installation. However, you 
must know exactly what you're doing, because 
the Core package may be missing critical exe- 
cutables or libraries. Usually, you'll have to 
add specific packages. We prefer the End User 
installation, because it tends to be more stable 
and flexible. Finally, add the manual pages. 
We find these to be a critical tool with little 
security risk. 

Once the system has rebooted after the in- 
stallation, be sure to install the recommended 
patch cluster and security patches. Also, be 
sure to use your go-between box to get the 
patches; the firewall box should always re- 
main on an isolated network. Patches are criti- 
cal to armoring a system and should always 
be updated. Bugtraq is an excellent source for 
following bugs and system patches. 

Eliminating services 

Once you've loaded the installation package, 
patches, and then rebooted, you're ready to 
armor the operating system. Armoring con- 
sists mainly of turning off services, adding 
logging, tweaking several files, and TCP 
Wrappers. 

First, we'll turn off the services. By default, 
Solaris is a powerful operating system that 
executes many useful services. However, most 
of these services are unneeded and pose a po- 
tential security risk for a firewall. The first 
place to start is / etc/inetd.conf. This file speci- 
fies the services for which the /usr/bin/inetd 
daemon will listen. By default, /etc/inetd.conf 
is configured for 35 services, but you only 
need two: ftp and telnet. You eliminate the 
remaining unnecessary services by comment- 
ing them out. 

The next place to start is /etc/rc2.d and 
/ etc/ rc3.d. Here, you'll find startup scripts 



• S73nfs.client — Used for NFS mounting a 
system. A firewall should never mount 
another file system. 

• S47autofs — Used for automounting. 
Once again, a firewall should never 
mount another file system. 

• S801p — Used for printing. Your firewall 
should never need to print. 

• S88sendmail — The MTA daemon that 
listens for incoming E-mail. Your fire- 
wall box shouldn't be your E-mail serv- 
er. However, your system will still be 
able to send mail, such as alerts. 

• S15nfs.server — Used to share file sys- 
tems, which is a bad idea for firewalls. 

• S76snmpdx — snmp daemon. 

Later, after you've completed both the OS 
and Firewall installation and configuration, 
you should turn off the following (other) 
/ etc/ rc2.d scripts: 

• S99dtlogin — CDE daemon, starts CDE 
or Open Windows by default. 

• S71rpc — portmapper daemon. 



Without these scripts, you can't launch a 
GUI interface. You most likely will want the 
GUI interface to help you with the installation 
and configuration. However, once you're 
done, there's no need for the GUI or either of 
the scripts. Both rpc and Open Windows or 
CDE have many exploitable ports and serv- 
ices. To see how many services are running 
with both the GUI and rpc running, type the 
command 

ps -aef ! wc -I 

Once you've finished with the installation 
and have turned off S99dtlogin and S71rpc, 
type the command again and compare how 
the number of services has decreased. The 
fewer services running, the better. 
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Logging and tweaking 

Once you've eliminated as many services as 
possible, you want to enable logging. Most 
system logging occurs in /var/adm. You need to 
add two additional log files there: sulog and 
loginlog. /var/adm/sulog logs all su attempts, 
both successful and failed. This allows you to 
monitor attempts to gain root access to your 
system, /var/adm/ Logi nlog logs consecutive 
failed login attempts. When a user attempts to 
log in five times, and all five attempts fail, this 
fact is logged. To enable the files, just touch the 
files /var/adm/ loginlog and /var/adm/sulog. 
Ensure that both files are chmod 640, as they 
contain sensitive information. 

Next comes tweaking. This involves vari- 
ous file administration tasks. The first thing 
you need to do is create the file /etc/issue. 
This file is an ASCII text banner that appears 
for all telnet logins. This legal warning will 
appear whenever someone attempts to log 
into your system. 

We also want to create the file /etc/ftpusers. 
Any account listed in this file can't ftp to the 
system. This restricts common system accounts, 
such as root or bin, from attempting ftp ses- 
sions. The easiest way to create this file is the 
command: 

cut -f1 -d: > /etc/ftpusers 

Ensure that any accounts that need to ftp to 
the firewall are not in the file / etc/ftpusers. 

Finally, ensure that root can't telnet to the 
system. This forces users to log into the system 
as themselves and then su to the root. This is a 
system default, but always confirm this in the 
file / etc/ default/login, where console is left 
uncommented. 

TCP Wrappers 

TCP Wrappers is a must for any firewall. No 
armored system should be without it. Created 



Listing A: Add the bottom two files to /etc/inetd.conf. 



# Ftp and telnet are standard Internet services. 



# 






#ftp 


stream 


tcp 


#te I net 


stream 


tcp 


# 






ftp 


stream 


tcp 


telnet 


stream 


tcp 



by Wietse Venema, TCP Wrappers is a binary 
that wraps itself around inetd services, such as 
telnet or ftp. With TCP Wrappers, the system 
launches the wrapper for inetd connections, 
which logs all attempts and verifies the at- 
tempt against an access control list. If the con- 
nection is permitted, TCP Wrappers hands the 
connection to the proper binary, such as telnet. 
If the connection is rejected by the access con- 
trol list, then the connection is dropped. 

Many of you may be wondering why a fire- 
wall would need TCP Wrappers, since the fire- 
wall does all that for you. The answer is 
simple. First, in case the firewall is compro- 
mised or crashes, TCP Wrappers offer a second 
layer of defense. Second, and just as important, 
TCP Wrappers protect against Firewall mis- 
configurations. We've often seen firewalls mis- 
configured, especially in VPN situations, 
allowing unauthorized users telnet access to 
the firewall. Third, TCP Wrappers add a sec- 
ond layer of logging, verifying other system 
logs. 

You can get TCP Wrappers from coast.cs. 
purdue.edu/pub/tools/unix. Once again, be 
sure to use your go-between system to retrieve 
and compile TCP Wrappers. We want to pro- 
tect the armored Solaris box within its isolated 
network. 

Once downloaded, be sure to review the 
README file first; it's an excellent introduction 
to TCP Wrappers. We recommend the follow- 
ing two options when compiling TCP Wrap- 
pers. First, go with paranoid, as this does a 
reverse lookup for all connections. Second, use 
the advance configuration, which is actually 
quite simple. This configuration keeps all the 
binaries in their original locations, which may 
be critical for future patches. 

Implementing TCP Wrappers will involve 
editing several files (these examples are based 
on the advance configuration). First, once com- 
piled, the tcpd binary will be installed in the 



i n . f tpd 
in. telnetd 

in.ftpd 
in. telnetd 



nowait root /usr/sbin/in.ftpd 

nowait root /usr/sbin/in. telnetd 

nowait root /usr/ loca I /bi n/tcpd 

nowait root /usr/local/bin/tcpd 
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/usr/local/bin directory. Second, the file /etc/ 
inetd.conf must be configured for the services 
that are to be wrapped, as shown in Listing A 
on page 3. Notice how inetd first launches the 
wrapper, / usr/local/bin/ tcpd, then the actual 
server daemon. Third, /etc/syslog.conf must be 



Listing B: Added to /etc/syslog.conf 



# Log all TCP Wrapper connections 
# 

loca 13. i nf o 
/var/adm/tcpd log 



Listing C: Example of /etc/hosts.allow and /etc/hosts.deny 

cat /etc/hosts.allow 

ALL: maggie.zeus, merlin: ALLOW 

cat /etc/hosts.deny 
ALL: ALL 



edited for logging tcpd, as we've done in 
Listing B. Last, the access control lists 
/ etc/hosts.allow and / etc/hosts.deny, shown 
in Listing C, must be added. 

Once all the proper files have been edited 
and are in place, restart /usr/bin/inetd with 
ki 1 1 -HUP. This will restart the daemon with 
TCP Wrappers in place. Be sure to verify both 
your ACLs and logging before finishing. 

Conclusion 

We've covered some of the more basic steps 
involved in armoring a Solaris box. The key to 
a secure system is having the minimal soft- 
ware installed, with protection in layers such 
as TCP Wrappers. There are many additional 
steps that can be taken, such as file permis- 
sions, backups, etc. Remember that no system 
is truly 100 percent secure. However, with the 
steps outlined above, you greatly reduce the 
security risks. 
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Real applications and the WWW 



by Paul A. Watters 

New programming languages come and 
go, but the responsibilities of application 
developers and programmers always 
remain the same. Applications have to be deliv- 
ered within a specific time frame, on budget, 
and more often than not in today's distributed 
computing environment, they have to be acces- 
sible. Meeting these requirements shouldn't 
require rewriting our code every year or so! In 
this article, we'll look at ways of making avail- 
able existing Solaris-based applications on the 
WWW that won't break the bank. 

Recycle and reuse 

Many programmers would associate the word 
reuse with C++ and other object-oriented lan- 
guages. We're going to look at it in a slightly 
different context, although the lessons learned 
can apply equally to procedural and object- 
oriented applications. Although it might seem 
heretical, many applications don't need to be 
rewritten every time a new programming lan- 
guage comes along, especially if rewriting 



isn't going to produce a tangible benefit (other 
than programmer satisfaction at using the lat- 
est technology, of course). 

Many people would argue that existing code 
that's UNIX-based should be rewritten in Java, 
for example, so that it's readily portable and 
instantly useable on any platform that has a 
Java interpreter. Sharing applications and mak- 
ing them as portable as possible is a good thing. 
However, many existing applications simply 
weren't written with a single workstation in 
mind; client-server architectures are still very 
useful for sharing large amounts of data for 
which it isn't efficient to have many copies lying 
idle on hard disks around the lab or the office. 
In addition, if our applications involve any kind 
of mathematical operations, it's often faster to 
use a workstation to display the results of oper- 
ations being performed by a multi-processor 
server that has no other overhead. With 64-bit 
server architectures on the way, we shouldn't be 
fooled into thinking that the humble PC will 
ever replace dedicated number-crunchers. 



CGI & WWW options 

But sticking with a client-server system for 
applications accessing large databases that 
require asynchronous updating, or just large 
amounts of data processing, doesn't mean that 
we need to sacrifice the benefits of being able 
to use applications through the WWW. We'll 
look at how to use the common gateway inter- 
face (CGI), which allows users with a WWW 
browser to run applications on a Solaris-based 
server. This method has the advantage of 
reducing code-development costs while taking 
advantage of existing applications and an 
existing set of protocols to exchange real-time 
data and respond to end-user requests. 

Most WWW users encounter CGI when 
they use a search engine to retrieve URLs, tele- 
phone numbers, and map directions. However, 
the specification allows for quite general 
exchanges of data between client and server. 
The interface is especially suitable for programs 
written in C (when using the POST method of 
sending a request from an HTML document), 
since this sends data in a form which can be 
read as a standard input stream. Existing data 
input routines that parse streams and extract 
variable values can then be used to retrieve val- 
ues entered by users from their Web page. The 
length in bytes of the input stream can be read 
from the environment by using 

getenv( "CONTENT_LENGTH" ) 

After our program has parsed the input, 
set appropriate variables, and completed its 
assigned task, the results can be sent through 
an output stream in HTML form by 

print f ("Con tent- type: text /html \n\n" ) ; 

after which, normally marked-up text and URLs 
will be displayed on the client's terminal. 

As an alternative to writing our own code 
to read and write through the CGI, we can use 
one of the many freeware C libraries available 
on the WWW for converting streamed data into 
variables. One such library is Eugene Kim's 
CGIHTML, which is easy to use and compiles 
successfully in the Solaris environment. Point 
your browser to 

www.eekim.com/software/cgihtml/ 

Case study 

CGI and C form the best partnership when the 
number of parameters passed to the server is 



small, but the computation required of the 
server is large. A good example might be the 
case of artificial neural networks, which are 
higher-order statistical models commonly 
used for modelling complex systems, such as 
the stock market. Although many neural net- 
work systems are available to run on PCs, 
either as C programs or as Java applets, the 
number of matrix operations that must be per- 
formed at each cycle becomes enormous when 
all the parameters associated with each data 
point presented to the network's "input layer" 
is computed. 

For the case of the stock market, if we 
wanted to predict more than just a few hun- 
dred points, many PCs would take well over 
one hour to compute a result. However, if the 
same PCs were used as clients who issued 
requests through their Web browser to a 
server with several UltraSPARC processors, 
the prediction might only take in the order of 
seconds or minutes, while the user can still 
work on their client computer without slow- 
ing down computation speed. 

An example neural network system for 
natural language processing, using this kind 
of client-server design is available at 

www.comp.mq.edu.au/~pwatters/semantic.html 

The purpose of this simulation is to 
retrieve a pronunciation for a word the user 
enters in a text box, along with two parame- 
ters that affect network performance. The sim- 
ulation is performed on a Solaris system with 
two UltraSPARC processors, and takes only 
several seconds to produce online output for 
each network cycle, and postscript graphs 
when the simulation has completed. This is a 
substantial improvement over ports made 
recently to PC-based systems, where each sim- 
ulation took several minutes to complete. 

Further reading 

If this case study has been convincing, by far 
the best place on the WWW to learn more 
about CGI programming is 

www.cgi-resources.com/ 

In this article, only the relationship between C 
and CGI has been discussed, but any Solaris- 
based programming language that can read 
streams (such as shell scripts and Larry Wall's 
PERL) could be used, depending on the appli- 
cation's goals, 
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Shell toolbox 1 01 , part 1 



by Jeff Forsythe, Sr. 

The tools we'll introduce in this article 
each have relative usefulness on their 
own, but when put together, they make 
up a very nice editing toolbox for any Solaris 
programmer or system administrator. Before 
introducing them, however, let's discuss a 
convention for keeping your scripts straight. 

Shell scripts 

Just like C program binaries, shell scripts ought 
to be kept in bin directories. This lets you know 
they're executable. Shell scripts get out of control 
if you don't organize them well. When organiz- 
ing, there are three types of scripts to consider: 
the script function, the script program, and the 
script library. 

The first type, the script function, is a func- 
tion written in your favorite shell script lan- 
guage. Functions are designed to be included 
in other shell functions or script programs. 
As a matter of convention, it's wise to store 
your script functions in a file with a .fnc 
(pronounced funk) extension instead of a 
.sh. This lets you know at a glance that it's a 
function rather than a script program. This 
differs slightly from an in-line function that's 
stored within a script program. A inc-type 



Listing A: Pseudo-code— 
get_response.fnc pseudo-code 

DisplayPromptf ) 
{ 

Display prompt 



get_response( ) 
f 

Repeat 

Di sp LayPrompt 
Get a response 
Test for validity 

Unti I Valid response 

Return response 



# END get_response. fnc 



function is designed to 
be used by more than one 
script program, whereas 
in-line scripts are designed 
to be called from within 
programs but have no 
outside reusability. In 
Listing A, let's look at 
a hypothetical function 
called get_response.fnc. 

Notice that the main 
function within this file is 
also called get_response. 
This is self-documenting 
and highly encouraged. 

If you know what the 
name of the .fnc is, then you 
know the name of the func- 
tion to call. The function 
calls the Di splayPrompt 



function. Di sp I ayPromp t has no intrinsic value 
outside ofget_response.fnc. Therefore, it's an in- 
line function. Later, if you write another function 
or script program that needs the same code, then 
Di sp layPrompt would be promoted to a .fnc. 

A good rule of thumb is: If a function is 
used by more than one script, then put it in a 
.fnc file by itself and include it in the others. 
Otherwise, put it in-line and call it instead. 

The second type of script is the shell script 
program. It's just that — a program written in 
the shell script language. This is what you nor- 
mally think of when talking about shell scripts. 
The shell program may have commands, vari- 
ables, in-line functions, include other scripts or 
.fnc functions, or have no functions at all, de- 
pending on its requirements. Scripts usually 
have the .sh, .ksh, or .csh extension, depending 
on which shell they were developed in. All ex- 
amples given here are in the Bourne shell (.sh). 

Finally, the third type of script is a shell 
script library. Like all libraries, the shell li- 
brary is a collection. It contains such things 
as included functions, script programs, and 
internal or environment variables. It could 
even include in-line functions or other li- 
braries. The purpose of the library is to make 
it easy to include all the necessary compo- 
nents of a given application. Library files 
should get a .shlib, .kshlib, or .cshlib exten- 
sion to differentiate them from the ever- 
popular C program .lib libraries. Now that 
we have the basic concept of functions, pro- 
grams and libraries, let's put them together to 
make something useful. 

Building an editing library 

In the rest of this article, and next month's 
issue, we'll build an editing library. It doesn't 
sound all that exciting, but when it's done, 
you'll be glad you did it. We'll need a few 
functions, some script programs, and perhaps 
some string and rubber bands to tie it all to- 
gether. We'll build and use most of these tools 
individually. Then, in order to make your life 
easier, we'll put them all together in a script 
library. Since they all relate to editing, we'll 
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name it edit.shlib. After that, whenever we need 
to perform editing functions, all we need to do 
is include the library (.edit.shlib) and we have 
all our tools available to us in one swoop. 

Edit library description 

Our shell library called edit.shlib includes the 
entire collection of editing tools as listed below: 

• shell.sh — Shell script editing front-end. 
Creates a documentation header and a 
framework for a script, and then calls the 
version control program (vc.sh). 

• file.sh — Same as shell.sh, but for non-shell 
script files such as configuration files, etc. 

• vc.sh — Version control shell. Performs 
version control based upon each user's 
individual configuration file, calls every- 
one's favorite editor (vi), and then calls 
affects.sh to see if the changes made 
affect other files. If so, you're asked if 
you'd like to edit the affected file(s), as 
well. This process is recursive, so an edit- 
ing session could potentially include any 
number of files. 

• affects.sh — Currently, vaporware (if you 
decide to build it, E-mail it to the author) 
lists the files that may be affected by the 
current editing change. It uses header.fnc 
to obtain information, meaning that this 
is only as good as the documentation in 
the header of the file. So, keep your doc- 
umentation current! 

• header.fnc — Displays the documentation 
header of the given file (created by 
shell.sh or file.sh). 

• logmsg.fnc — Log message function. Logs 
the date, time, calling program, message 
type, and message to the given log. 

This library or its individual elements (like 
any other library or script) can be included 
in other libraries, a .profile, a shell script, or 
at the command line. This is especially use- 
ful so that you can use the library contents 
from the command line. This particular 
library was built with that usage specifically 
in mind. For instance, if you're interested in 
the documentation of a particular file, you 
can use the header function to retrieve it. If 
you included the library in your .profile, all 
you need do is type header filename and the 
header information is returned to you. Oth- 
erwise, type: . path/edit, shlib, and then the 
header command. This is quite useful. 



Background information 

We'll look at each of the scripts individually, 
but the main emphasis here is to talk about 
them collectively as a library. Each tool was 
built over the last six years or so, as a need 
arose, but based in whole or in part on the 
previous work. 

For instance, shell.sh is a neat little tool that 
was written about six years ago as a front end 
to vi. It asked a few questions, created a header, 
and then threw you into vi to create your file. 
In earlier versions, it checked to see if the file 
existed, asked if you wanted to edit or over- 
write the file, and performed some other minor 
tasks. Since adding the version control pro- 
gram, this has become unnecessary. Version 
control was added as an add-on to shell.sh. Of 
course, shell.sh was affected by this addition, 
thereby creating the need to modify it. This 
brought up the idea for the affects.sh script. 
Your shell tools have undoubtedly developed 
the same way, or if you're new, they will. They 
just might not be in library form yet. Take the 
time and do that today; it will save you count- 
less hours later. 

The version control script is patterned after 
one found in an article in another publication 
about four years ago ("Sys Admin" Vol. 3, No. 
5 Sept/Oct 1994). The methodology used in 
the original article's script and in vc.sh was 
borrowed from DEC's VMS file naming con- 
vention. The filenames on VMS end with a 
semicolon and a sequential number. It's no 
replacement for commercial version control 
packages, but it works well, it's very easy to 
implement, and, best of all, it's free! 

Start building 

First, build the logmsg.fnc, as shown in Listing 
B on page 8, because it has the greatest utilitar- 
ian function on its own, and is a basic building 
block for the rest of the library. You probably 
already have your own logging script that will 
readily adapt (if yours is better, E-mail a copy to 
the author). Just remember to modify the 
logmsg calls in the other scripts if you use your 
own. After logmsg.fnc, build header.fnc, which 
is found in Listing C, also on page 8. The 
header of a file (as with all internal documenta- 
tion) is extremely important. You can never over- 
document a program, no matter how simple it 
seems at the time. A year or two from now 
you'll wonder why a counter is initialized to 4 
and not 0 or 1. Good header documentation 
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Listing B: logmsg.fnc Listing 



#! /bi n/sh 


# FUNCTION: 


path/ logmsg . f nc 


# ARGUMENTS: 


prog : $0 


# 


msg-type : 


# 


S Jl START 


# 


M Ji MESSAGE 


# 


E Ji ERROR 


# 


F Jl FINISH 


# 


"msg" : Message 


# 


log : log file 


# 




###################################### 


logmsgl ) 




{ 




echo '"date ■» 


%m/%d/%Y" rdate \ 


+ %H:%M:%S'!$1 


!$2!$3" » $4 


exit 0 




} 




# END Logmsg . 


f nc 



will explain the 4 and header.fnc will make it 
easy to find out why. Yeah, you could just pg 
the file, but that gives you everything, not just 
the header. The header is also a nice thing to 
have in a hardcopy documentation folder. 

The header in Listing C has been gutted in 
the interest of the publication. Only required 
information is included. The calling program 
must include the logmsg.fnc. Then, it can be 
called such as the example in Listing D. 

The log provides you with invaluable 
information for many applications, including: 

• Reporting programs (to search for errors) 
to determine if a program has finished 

• Determining at what point a program is 
running or if it's hung as part of a lock- 
ing mechanism (A nice topic for a future 
article — don't you think?) 

Headers are enclosed within two lines of 
57 # signs. That has been shortened to 38 here 
for publication reasons, but the script checks 
for 57. You may use any character to separate 



Listing C: header.fnc Listing 



#!/bin/sh 

####################################### 

# FUNCTION: header.fnc 

# USAGE: header f i lename 

# ARGUMENTS: fi lename 
# 

###################################### 

header( ) 
{ 

if [ $# -ne 1 ] 
then 

echo "USAGE: header filename" 
exi t 1 



f i 



if [ ! -s ${1} ] 
then 



echo "Can't find ${1}" 
exit 2 



fi 



IFS=" 



C0UNT=0 

for LINE in 'cat ${1}* 
do 

echo ${LINE} 
if [ "${LINE}" = 

"########################### ## #### ####################### 

r i 

then 

COUNT=~expr ${C0UNT} ♦ V 

fi 

if [ ${C0UNT} -eq 2 ] 
then 
exit 0 

fi 
done 
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the header lines but do not use any asterisks 
(*) in any of your lines, unless required. Suf- 
fice it to say that a disaster occurred, long 
ago but never forgotten, that caused 57 phar- 
macy stores to close down, just because a 
pound sign was missing and a line of aster- 
isks followed. The author is proud to be the 
one who found the problem and not the one 
who caused it. This gives your toolbox a 
start. Next month, we'll expand our toolbox 
even further, 



Listing D: logmsg Include, Call and Output 
. ${FNCDIR}/logmsg.fnc 

logmsg $0 F "FINISH" ${HOME}/logs/examp. log 

08/12/1998106:31 : 1 9 I examp . sh I S ! START 
08/12/1998!06:32:04!examp.sh!M! Regular msg 
08/ 12/ 1 9981 06: 33: 47! examp. sh IE! Error msg 
08/12/1998106:34:21 ! examp . sh ! F ! FINISH 
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Configuring Network Interface Cards 



by Lance Spitzner 

This article is the first of a two-part series 
In this first article, we'll cover how to 
configure, troubleshoot, and modify sys- 
tem interfaces. The second article will cover 
static routing tables for systems with two or 
more interfaces. In both articles, we'll be focus- 
ing on TCP/IP in an Ethernet environment. 

Interfaces 

Network Interface Cards (NICs) are what allow 
your system to talk to the network. When they 
don't work, neither do you. Our goal is to get 
your interface up and properly running. 

The first place to start is installing and test- 
ing the hardware. Once you've installed the 
hardware, SPARC systems can be tested at the 
EPROM level to verify the NICs. Use the man- 
ual that accompanies the interface card on 
how to test that specific card. 

Solaris x86 is a little different, as there is no 
true EPROM, and the drivers are different. How- 
ever, Solaris x86 2.6 is Plug and Play compatible, 
and we've had fairly good luck adding NICs. 

Once you've confirmed at the hardware 
and driver level that everything works, the 
fun can begin. The place to start is the ifconfig 
command. This powerful command allows 
you to configure and modify your interfaces 
in real time. However, any modifications 
made with ifconfig aren't permanent. When 
the system reboots, it will default to its previ- 
ous configuration. First, I'll show you how to 
make all modifications with the ifconfig com- 



mand. The second half of this article will cover 
making these modifications permanent by 
modifying the proper configuration files. 

ifconfig 

I'll show you which interfaces are currently 
installed and active. Remember, just because 
you added the physical network interface card 
doesn't mean it's active. If you do an ifconfig 
before you've configured the device, the inter- 
face won't show up. Once configured, how- 
ever, the typical output of the ifconfig 
command would look like this: 

1 00 : f I a g s =849<UP , L00PBACK , RUNN I NG . MULT ICAST> 
mtu 8232 

inet 127.0.0.1 netmask HOOOO0O 
hme0 : f I ag s=863<UP , BROADCAST , NOTRAI LERS , 
RUNNING. MULTICAST mtu 1500 

inet 192.168.1.132 netmask ffffffOO 
broadcast 192.168.1.255 

ether 8:0: 20: 9c : 6b :2d 

Here we see two interfaces, loO and hmeO. loO is 
the standard loopback interface found on all 
systems. hmeO is a 10/100Mbps interface. All 
hme interfaces are 10/100Mbps, all le interfaces 
are 10Mbps, all qe interfaces are quad 10Mbps, 
and qfe interfaces are quad 10/ 100Mbps. 

There are three lines of information about 
the interface. The first line is about the TCP/IP 
stack. For the interface hmeO, we see the sys- 
tem is up, running both broadcast and multi- 
cast, with an mtu (maximum transfer unit) of 
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1500 bytes — standard for an Ethernet LAN. 
Notrailers is a flag no longer used, but kept for 
backwards compatibility reasons. 

The second line is about the IP addressing. 
Here we see the IP address, netmask, in hexa- 
decimal format, and the broadcast address. 
The third line is the MAC address. Unlike most 
interfaces, Sun Microsystems' interfaces derive 
the MAC addressing from the NVRAM, not 
the interface itself. Thus, all the interfaces on a 
single SPARC system will have the same MAC 
address. This doesn't cause a problem in rout- 
ing, since most NICs are always on a different 
network. Note that you must be the root to see 
the MAC address with the ifconfig command; 
any other user will only see the first two lines 
of information. 

The first step in bringing up an interface is 
"plumbing" the interface. By plumbing, we're 
implementing the TCP/IP stack. We'll use the 
above interface, hmeO, as an example. Let's 
say we had just physically added this network 
interface card and rebooted; so, now what? 
First, we plumb the device with the plumb 
command: 

ifconfig hme1 plumb 

This sets up the streams needed for 
TCP/IP to use the device. However, the 
stack hasn't been configured, as you can 
see below: 

hmeO : flags =842<BR0ADCAST . RUNN I NG , 
MULTICAST mtu 1500 

inet 0.0.0.0 netmask 0 

ether 8 : 0: 20:9c : 6b :2d 

The next step is to configure the TCP/IP 
stack. We configure the stack by adding the IP 
address, netmask, and then telling the device 
it's up. All this can be done in one command, 
as seen below: 

homer #i f con f i g hmeO 192.168.1.132 
netmask 255.255.255.0 up 

This single command configures the entire 
device. Notice the up command, which initial- 
izes the interface. The interface can be in one 
of two states, up or down. When an interface 
is down, the system doesn't attempt to trans- 
mit messages through that interface. A down 
interface will still show with the ifconfig com- 
mand; however, it won't have the word up on 
the first line. 



Virtual interfaces 

A virtual interface is one or more logical inter- 
faces assigned to an already existing interface. 
Solaris can have up to 255 virtual interfaces 
assigned to a single interface. 

Once again, let's take the interface hmeO as 
an example. We've already covered how to con- 
figure this device. However, let's say the device 
is on a VLAN (virtual LAN) with several net- 
works sharing the same wire. We can configure 
the device hmeO to answer to another IP ad- 
dress, say 172.20.15.4. To do so, the command 
would be the same as used for hmeO, except the 
virtual interface is called hmeO:*, where * is the 
number you assign to the virtual interface. For 
example, virtual interface one would be hme0:l. 
The command to configure it looks as follows: 

ifconfig hme0:1 172.20.15.4 
netmask 255.255.0.0 up 

Once you've configured the virtual inter- 
face, you can compare hmeO and hme0:l with 
the ifconfig command. 

hme0: flags =843<UP , BROADCAST , 
RUNNING, MULTICAST mtu 1500 

inet 192.168.1.132 
netmask ffffffOO broadcast 192.168.1.255 
ether 8:O:20:9c:6b:2d 
hme0:1: f lags=842<BR0ADCAST, 
RUNNING. MULTICAST mtu 1500 

inet 172.20.15.4 
netmask ffffOOOO broadcast 172.20.255.255 

Here you see the two devices, both of 
which are on the same physical device. Notice 
how the virtual interface hme0:l has no MAC 
address, as this is the same device as hmeO. 
We can repeat this process all the way up to 
hme0:255. The operating system and most 
applications will treat these virtual devices 
as totally independent devices. 

Configuration files 

You now know how to configure your NICs. 
Unfortunately, any modifications, additions, 
or deletions you make with ifconfig are only 
temporary; you'll lose these configurations 
when you reboot. Now, I'll discuss what files 
you have to configure to make these changes 
permanent. 

The place to start is the file /etc/hostname.* 
(where * is the name of the interface). In the case 
of hmeO, the file name is /etc/hostname.hmeO. 
The virtual interface hme0:l would have the 
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filename /etc/hostname.hmeO:l. This file has a sin- 
gle entry — the name of the interface. This name 
is used in the /etc/hosts file to resolve name to 
IP address. 

The file, /etc /hostname.*, is critical; this is 
what causes the device to be plumbed. During 
the boot process, the /etc/rcS.d/rootusr.sh file 
reads all the /etc/hostname.* files and plumbs 
the devices. Once plumbed, the devices are 
configured by reading the /etc/hosts and the 
/etc/netmasks file. By reading these two files, 
the device is configured for the proper IP and 
netmask, and brought to an up state. 

Let's take the device, hmeO, as an example. 
During the boot process, /etc/rcS.d/rootusr.sh 
looks for any / etc /hostname.* files. It finds 
/etc/hostname.hmeO, which contains the fol- 
lowing entry: 

Homer 

The shell file /etc/rcS.d/rootusr.sh looks in 
/ etc /hosts and resolves the name homer with 
an IP address of 192.168.1.132. The device, 
hmeO, is now assigned this IP address. The 
script then looks at /etc/netmasks to find the 
netmask for that IP address. With this infor- 
mation, the startup script brings up interface, 
hmeO, with an IP address of 192.168.1.132 and 
a netmask of 255.255.255.0. It may seem re- 
dundant having the script review the netmask 
of a class C address. However, don't forget 
that, starting with 2.6, Solaris supports both 
classless routing and VLSM (Variable Length 
Subnet Masks), both of which we'll discuss in 
next month's issue. 

As you've seen in this example, there are 
three files that must be modified for every 
interface. The first is / etc/hostname.*, which is 
the file you create to designate the interface's 
name. The second file is /etc/hosts, where you 
resolve the IP to the interface name. Last is 
/ etc/ netmasks, which is where you define the 
netmask of the IP address. 

Troubleshooting 

Once you've mastered the tricks to modifying 
your interfaces, troubleshooting should be eas- 
ier. You should look for several things when 
troubleshooting an interface. 

First, when working with an unfamiliar 
machine, often you don't know how many 
physical interfaces are on the machine. A 
quick way to tell is use dmesg; this will give 
you information on the physical hardware. 



Look for leO, qfeO, hmeO, or qeO. These are the 
names assigned to the physical devices. 

If an interface isn't responding to the net- 
work, check to be sure it's the correct IP address 
and netmask. The ifconfig command is a quick 
and temporary way to change IP and netmask 
information for troubleshooting purposes. 

Mtu is another possibility. Some systems 
may have problems communicating due to 
fragmented packets. Changing the mtu size 
may solve that problem. You'll notice that you 
didn't have to set the mtu size in the examples 
above; these are set to defaults automatically, 
such as 1500 for Ethernet interfaces. 

If that fails, try bringing the face down, and 
then re-initializing it with the up command. If 
nothing else works, unplumb the device, and 
then plumb it again. Basically, this reinstalls 
the TCP/IP stack. 

Conclusion 

Network Interface Cards are critical to your 
systems networking capability. Understanding 
the configuration of your interface(s) ensures 
your system's productivity Next month, we'll 
look at routing tables and ensuring that once 
your interfaces are configured and up, your 
packets will know where to go. 



What's Coming 

Over the last few months we've received feedback about 
what you, our reader would like to see in Inside Solaris. 
Coming next month you'll find articles that cover: 

• CGI scripts and data security 

• Process and Thread Scheduling 

• Continuation of our Shell toolbox 

As we move into 1999 we plan to also feature articles 
that will focus on: 

• Configuring PPP 

• Alternate PPP software 

• Network routing 

• Jumpstart 

If there are any other topics that you would like to see 
covered or are interested in becoming a writer yourself, 
please drop me an E-mail at gsuhm@tacticsus.com. 

Garrett Suhm 
Editor 
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Shells 

by H-W Schlote 

I n the article "Shell toolbox 101, part l"on 
I page 6, we discussed building libraries of 
I shell scripts. Let's take a step back now and 
give some background on the various UNIX 
shells that are available. It can be useful to know 
what else is available, even though most users 
only know the one they use. 

Background 

According to Funk & Wagnalls New 
Encyclopedia: 

SHELL or SEA SHELL — hard, largely calcareous 
skeleton of marine animals, especially the mollusks 
C see Mollusk ). Because of their beauty, bright col- 
ors, variety in shape, and abundance on sea- and 
lake-shores, shells have long been used for orna- 
mentation, tools, and coins. They are important 
today in the production of such items as "pearl" 
buttons, jewelry, and other decorative items. Shell- 
collecting is a popular hobby throughout the world. 



Figure A 




Here's the principal view of the shell's functionality. 



So, why is the thing with the prompt 
where we type in commands called a shell? 
Because, it surrounds the UNIX core, as 
shown in Figure A. The shell is a program that 
listens to your terminal. It accepts and inter- 
prets the commands you type and turns them 
into requests to the underlying kernel, to per- 
form the work you want. 

There's some jewelry to find. In the dark, 
old days when I moved from DOS to UNIX, I 
couldn't understand how people could be sat- 
isfied without command line editing or the 
ability to move the cursor up and edit the last 
command. Even today, shells providing com- 
mand line editing, even in this simple form, 
are exceptions. But, on the other hand, there's 
the one shell with a nearly complete set of 
emacs (the famous editor — originally written 
by Richard Stallman for PDP-10) commands, 
including searching backward. 

If you compare the UNIX operating system 
with a car, then the steering wheel is part of 
the user interface. The shell can be thought of 
as the user interface to UNIX. Just as you can 
have servo steering in your car, one shell may 
offer a lot of conveniences, while others leave 
you with nearly no support at all. 

This article covers just a few topics and 
examples about shells. It concentrates on inter- 
active shells and makes no claim to be exhaus- 
tive. Maybe it will help you to decide which 
shell is the right one for you. If you want to go 
into detail, have a look at the references given 
at the end of this article. 

Shell flavors 

There are many different UNIX shells avail- 
able, including ash, bash, csh, choice, ksh, pdksh, 
smash, sh, and tcsh. In general, they can be 
divided into two groups: the Bourne shell 
compatible ones, and the C shell compatible 
ones. I'll focus here on the five most popular 
shells: 

• The Bourne shell (invoked as sh) is the 
oldest shell and often referred to as the 
standard shell. 



• The C shell (invoked as csh) uses C syn- 
tax. Compared to the Bourne shell, it 
offers more features. But, using some of 
the simple features, like redirecting out- 
put and dividing stdout and stderr, isn't 
really straightforward. I'll show later 
how this can be done. 

• The Korn shell (invoked as ksh) is a super- 
set of the Bourne shell that lets you edit 
the command line. There are restrictions 
for the Korn shell, but lots of things can 
be configured. A public-domain version, 
pdksh, exists also. 

• The GNU extended C shell (invoked as 
tcsh) provides command line editing 
with cursor up/ down functionality. 

• The GNU Bourne-Again shell (invoked as 
bash) is the crown of all shells. It's a 
superset for the ksh and understands 
almost every csh command, bash is ulti- 
mately intended to be a conformant 
implementation of the IEEE POSIX Shell 
and Tools specification (IEEE Working 
Group 1003.2). 

The disadvantage of the last two shells is that 
they consume a lot of resources. This is one of 
the reasons why many system administrators 
prefer not to install any of them, but stay with 
the shells provided by their hardware vendor. 
Normally, these are the first three shells men- 
tioned (sh, csh, and ksh). 

Output redirection 

Shells know about standard file descriptors. 0 
means s t d i n, 1 corresponds to s t d o u t , and 2 is 
stderr. If you want to redirect output, you 
have to specify which output and do this by 
giving the number of standard file descriptor 
for sh, ksh, and bash. This results in 

cmd 1> cmd.out 

or shorter 

cmd > cmd.out 

to redirect stdout to file cmd .out. The second 
(short) form is the correct syntax for csh, too. 
Things differ if you want to redirect stdout to 
file cmd.out and stderr to cmd .err. I use this very 
often. Remember that stderr is unbuffered, 
whereas stdout is at least line buffered. So, if 
you don't separate stdout from stderr, all you 
have is a mess of a message file. 



For sh, ksh, and bash, we simply have 

cmd 1> cmd.out 2> cmd. err 

Unfortunately, ( t )csh only offers the choice 
to either redirect stdout alone or to redirect 
stdout, as well as stderr. Therefore, we have 
to use grouping to get the correct result: 

(cmd > cmd.out) >& cmd. err 

This means redirect stdout to cmd.out, and 
afterwards that is all that's left to cmd . err. This 
isn't really straightforward, but at least it works. 
If you build a C program and you start a pro- 
gram in a csh via a call to exec, you really run 
into trouble if you want to distinguish stdout 
and stder.r. 

On the other hand, redirecting both stdout 
and s t d e r r to one file is very simple in c s h, but 
results in some thinking or a look into the man- 
page or other documentation for Bourne shell 
compatibles. If you want to redirect both stdout 
and stderr to file cmd.out you type in csh: 

cmd >& cmd.out 

and 

cmd > cmd.out 2>&1 

in one of sh, ksh, or bash. The latter command 
reads redirect stdout to file cmd.out and redirect 
stderr to stdout. But, as mentioned before, 
cmd . ou t will most probably be garbled by 
strings from stdout and stderr. 

Command line editing 

Command line editing with cursor up / cursor 
down functionality is only provided by tcsh and 
bash. The standard shell, sh, doesn't provide any 
command line editing at all. The ksh provides 
the fc command. If you're used to it, you get 
along with it quite well. The csh offers a set of 
command substitutions from quick substitution 
to sed (the famous stream editor) syntax. 

I must admit that I'm not able to remember 
all these fancy substitutions and recall com- 
mand syntax. I prefer using the cursor up key, 
and the last command is there to be edited, 
and when I want to execute once again the last 
command containing string too, I want to type 
[ Ct r L ]R f oo like I do in emacs. This thing is 
offered by bash only, tcsh isn't bad. Most of the 
time, you'll use cursor up /down to re-execute 
commands anyway. 
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Adjusting the prompt 

Unfortunately sh, csh, ksh, and tcsh don't offer a 
lot of possibilities to adjust the prompt. In gen- 
eral, the environment variable PS1 holds the 
primary prompt string and can be changed to 
adjust the prompt to your personal choice. If 
environment variable PR0MPT_C0MMAND is set, the 
value is executed as a command prior to issu- 
ing each primary prompt for some shells. Thus, 
changing PS1 wouldn't result in any change 
because normally variable PR0MPT_C0MMAND resets 
PS1. In this case, you have to unset variable 
PR0MPT_C0MMAND first. 

Normally, UNIX users work on more than 
one machine. Consequently, the information 
the prompt should provide is which machine 
he is currently using and the current working 
directory. But, I don't want to see the name of 
my home directory in my prompt, if I'm some- 
where below it. 

In bash, I define PS1 to be "\h:\w\$ " (the 
string inside the double quotes). This results in 
the hostname, followed by the current working 
directory. But, if the current working directory 
starts with my own home directory, the name 
of my home directory is substituted with ". \$ 
results in $ for normal users and # for the 
super-user. 

Using the definition for PS1 given above, 
my prompt looks like: 

Gandalf: "/Solaris. Inside/shells 

If you want to have the current user included, 
you simply add \u somewhere to PS1. This is 
easy, isn't it? 



For all other shells, you can define scripts 
to produce the same results. This leads to exe- 
cuting a script each time [ENTER] is pressed, 
and results in consuming a lot of system re- 
sources by just printing the shell prompt. So, 
if you want to use one of the more simple 
shells, you should stay with a simple prompt, 
like %. 

Conclusion 

In this article, I provided some remarks about 
popular shells. The main differences lie within 
interactive use. Programming syntax differs 
between these shells, too, but almost every- 
thing you can perform with one shell, you can 
perform with the others, also. It's just a matter 
of syntax. But, for reasons of efficiency and 
saving resources, I suggest using the ksh for 
programming. 

Availability 

The following shells are part of the Solaris 
operating system: sh, csh, ksh, bash, and tcsh 
can be obtained for example from 
sunsite.unc.edu. 

Further reading 

• Introducing UNIX System V by Rachel 

Morgan and Henry McGilton, McGraw-Hill 

0 UNIX in a Nutshell by Daniel Gilly and the 
staff of O'Reilly & Associates, O'Reilly & 
Associates *22k 



Are you a good tipper? 

Do you have any great Solaris tips that with your E-mail and/or Web address. Send 

you've discovered? If so, send them our your tips to sun@zdjournals.com, fax them 

way! If we use your tip, it will appear on to (716) 214-2386, or mail them to 
our weekly online ZDTips service. Visit 

www.zdtips.com to check out all our avail- The Editor, Inside Solaris 
able tips. We may also publish it here in 500 Canal View Boulevard 

Inside Solaris. Your byline will appear along Rochester, NY 14623 



14 



Inside Solaris 



HARDWARE HUNTING 




INSIDE' 



Sun on a budget 



Amazing things have happened 
to hardware in the Sun world 
in the last year. Sun has come 
out with all new workstations that 
really push the price/performance 
ratio to new heights. Both the Ultra 5 
and Ultra 10 lines are both affordable 
and powerful. But these aren't your 
only options if you need to set up a 
workstation on a budget. 

Old but not forgotten 

Because of Sun's aggressive pricing, 
used Sun equipment has never been 
a better deal than now. Last-genera- 
tion Sun workstations Such as Sparc 



10's and Sparc 20's that had sold 
for tens of thousands of dollars 
new can be found for very reason- 
able prices on the used market. 

They may not have the latest 
UltraSparc CPU's, but machines 
like the Sparc 20 have the ability 
to handle four processors as well 
as SCSI I/O (which the Ultra 5 
and Ultra 10 workstations lack 
without add-on cards) and are 
built like tanks. These machines 
make perfect firewalls, news 
servers, and mail servers, as well 
as an inexpensive way to test for 
a Sun developer to acquire a 
workstation for home use. 
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This month we will review some of the 
more popular sources for used Sun equip- 
ment. In the coming months we will ex- 
plore the used Sun market and show you 
the advantages (and disadvantages) of buy- 
ing used equipment. For now, check out 
Table A for a sample of used Sun equip- 



ment vendors. This list is not exhaustive, 
but it is meant to give a sample of what is 
available in the used market. If you have 
your own favorite used Sun equipment 
vendor, send me an E-mail at gsuhm® 
tacticsus.com and we will share these with 
our readers. 



Table A: Some vendors of used (and new) Sun equipment 



Company 


Description 


Web Site/Phone# 


Rave Computer 
Association Inc. 


Reseller of used and 
refurbished Sparc, UltraSparc 
and Sparc Clones built by Rave 


www.rave.com 
(800) 966-RAVE 


Apcom Systems Inc. 


New and used Sun equipment 
And Sparc clones. Online quote 
generator is available on their 
Web site 


www.apcom.com 
(888) 422-0867 


Integrated Solutions 
Group Inc. 


Used Sparc and UltraSparc 
workstations, servers and 
peripherals 


www.isgsun.com 
(425) 882-0400 


Sun Data 


Reseller of a variety of 
workstations and servers 
from various vendors. Flexible 
on-line quote generator 


www.sundata.com 
(888) SUN-DATA 


EIS Computers Inc. 


Used Sparc and custom-built 
clones. Also OEM for Solaris 
X86 machines 


www.eis.com 
(800) 351-4608 


Minicomputer 
Exchange Inc. 


Specialize in used Sun and 
Silicon Graphics hardware. 


www.mce.com 

(888) 733-4400 
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